Jul 10, 2010

Meeting Date: 
Saturday, July 10, 2010

Class

 

Bruce Weimer - "Face recognition"

Bruce explained today how robots can "recognize faces" detected by a camera. This technique is used in the Leaf platform.

Here is the handout with some extra links

 

 

 

 

Business meeting

upcoming classes:

  • August: "Robot Locomotion" - Thomas Messersmidt
  • September: "Machine Intelligence" - Martin Mason
  • October: "GPS-based robot Navigation" - Martin Larocque

upcoming contests:

upcoming events:

December: Talent show

Auction

This month, our member could bring their junk and auction it off, usually for pennies on the dollar.

Don Fears sold a Min Robosapien, a robot dog ($5) and a toy battlebot ($1)

Alex sold two VHS-type camera's for $3, and two gear motors used to position antenna's. They provide 20 ft/lbs, no encoder but have a brake. 24V has to be applied to release the brake. Both were sold for $45.

He also sold a CMUcam for $20.

 

 

 

 

 

 

 

 

 

Thomas Messersmidt emptied out his garage completely voluntary (his wife had nothing to do with it whatsoever), and offered us a rare opportunity to acquire some fine antique and other valuable artifacts at budget prizes: he sold:

  • Evil genius book ($6)
  • Roomba ($2)
  • vintage voltmeter ($1) 
  • Hoverpod ($2)
  • set of Asimov books ($2)
  • Wowwee robopanda ($4)

He was unable to sell an iRobot Create, full with controller (value new approx $200). He accepts any reasonable offer.

Thomas, who gets filthy rich running his online robot shop "Robots-and-Androids-and-more" made some donations to the pool of competition prizes that people can win by competing in one of our many robot contests.

Show & Tell

Jim showed us a mold for bending Lexan.

Purpose is to heat up a piece of Lexan in an oven, then gently bend it to the right form in the mold.

Follow this link for more information.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Alex Brown continued his presentation on his SCORBOT robot arm from last month when he couldn't get it working. He thinks he might have mistaken a NULL MODEM cable with a regular serial cable. He wrote an article on this robot.

All motors have encoders. Alex was wondering if there was a way to replace some motors with new ones that have no encoders (which are cheaper, motors with encoders are in the $200 range) or to find a way to replace the existing encoders. The problem is that the shafts are very short and difficult to mount anything on them. One solution is to mount a potmeter, but then you need an A/D converter.

He is replacing the stock controller, which somewhat resembles a boat anchor in weight and usefulness. He is reverse-engineering the controller. Currently he controls the robot via a Netbook PC, linked to the controller (to be replaced with a custom or COTS controller) over a serial cable.  The original controller comes with a DOS program that runs on a Windows XT. He rewrote the software in C/C++. He found that the data returned from the controller is unrealiable and suggests repeat commands to ensure that at least one of them is sent.

 

The purpose of the SCORBOT is to give Alex some experience with robot arms. SCORBOT itself is too heavy to be mounted on his Rocky mobile LEAF robot, or at least the base is. Alex brought up the topic of how to mount a robot arm on a light-weight LEAF-type robot platform.

It was suggested to make 2 sheet metal hollow boxes (to keep the weight down) like in the picture here. The shaft will go through the two boxes, which are mounted to the side of the robot.

 

 

 

 

 

 

 

 

 

Here is a video of the SCORBOT demo program:

Here are a couple more detailed pictures of the robot arm:

 

Rainer Hessmer brought his self-balancing robot platform, which he showed us last month. It has greatly improved. He was so confident that he took a ride on it himself. You can find more information on his website.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

John Davis showed the RoboMagellan robot he is working on. 

He chose an Offroad 4x4 RC Monster truck as a base for his robot. It has nice all-terrain wheels and suspension, which is crucial for RoboMagellan contests.

For the brains of his robot, he opted for the Beagleboard open-source embedded Linux single-board computer. This little puppy stores some serious computing punch. He also liked that it is Linux, which is what John is familiar with. The Beagleboard is very interesting for a robot brain, because it is extremely low-power for that class of computing power.

Traditional robots use peripherals (sensors, controllers) which are interfaced to the brains via I2C, SPI and serial. John didn't want to deal with all that low-level stuff and opted for all-USB parts. He installed a USB-hub and acquired all peripherals with a USB interface, like a GPS, keyboard, mouse, R/C motor controller.

For the motor controller, he chose the Pololu Micro Maestro USB servo controller.

His compass only has a TTL interface. He connects it to Micro Maestro, which support an extra TTL serial port. Micro Maetro comes with virtual COM port drivers, which allows the software to see each peripheral as a standard COM port, which is one of the easiest ways of interfacing with an external device.

The robot has 3 motors: two DC motors for drive and one servo motor for steering . 

John also posted the following interesting experience with navigating his robot via GPS. He concluded that GPS is very inaccurate/unreliable for maintaining a stable compass heading when traveling at walking speed. An additional dedicated compass sensor is needed.

I'm working on an entry for our upcoming RoboMagellan contest in August. The robot uses GPS only. Heading is calculated after it begins to move. Speed is a good walking pace, ~2-3 mph. I've learned the hard way that this navigation method doesn't work and I  thought I would share for your amusement. 

For development, I logged 11.5 minutes of GPS sentences while I walked from home to the library. That log was then replayed into the same serial port that the GPS would normally occupy. Library entrance coordinates were entered as the goal. Watching the robot on the stand, it looked like it was steering appropriately.

Yesterday I took it out to the empty civic center parking lot to a starting point nearer the library. It went wild! Sometimes it looked like it might be turning toward the library, but it always ended up making a big circle. It didn't get stuck in the same circle; it would break out, change direction, and find another loop.

Here's why: The log shows that calculated heading varies wildly from one GPS reading to the next. (Std dev ~10 deg.) This is true whether the robot does the math or if it reads the heading from the GPRMC sentence. Another source of error is that when the robot is in a turn, one second is too long an interval between readings. At 3 mph, the 
robot has traveled about four and one half feet in one second. The calculated heading will significantly lag the true heading, leading to severe over-correction.

I'm convinced now that for slow speeds you need a fast compass to easily determine heading. There are several digital compass modules with I2C or serial interfaces, available online for ~$30-50.